This document gives guidance on the current data types in use in HSCIC interoperability specifications at the time of publication. It is not a complete HL7 data type definition (HL7 Ballot 2006 is the source if this is required) but more of a guide for implementers on how to utilise the data types in HL7 message instances. The overview of a data type therefore may not contain all elements or attributes as specified in the HL7 ballot.

Artefacts contained within this guidance fall into three types:

• HL7 V3 data types - Within this guidance, a [D] after the name indicates a data type. Note: one data type may be constrained by another data type.
• NHS England data type flavors (flavours) - Within this guidance, an [F] after the name indicates a data type flavor.
• NHS England data type extensions - Within this guidance, an [E] after the name indicates a data type extension

Descriptions for each of these artefacts are contained in the relevant following sections.

The terms attribute and element can be a bit confusing as they can have different meanings whether the reference is to the HL7 V3 model or the XML instance. Therefore, within this guidance the following terms are used.

• HL7 V3 model attribute - this is an attribute as shown on a HL7 V3 model for example a patient class has a HL7 V3 "id" attribute to carry the NHS number.
• XML element - This is an actual XML element which may have attributes and/ or sub elements
• XML attribute - this is an actual XML attribute of an XML element.

To illustrate the reasons for this clarification see the example below:

A patient class in a HL7 V3 model has a HL7 V3 model attribute called "id", this equates to an XML element called "id" within the "on the wire" message instance and the XML element has XML "id" attributes called "root" and "extension".

This document gives guidance at a data type level. There is an XML representation of each data type, and the schemas for these are in the file called datatypes.xsd. For some attributes, (for example address part type of element “addr”), as permitted by HL7 V3 regulations, UK-specific attribute values have been used rather than the standard HL7 V3 set.

The data types listed below are derived from the full HL7 V3 data types as these were defined in 2006 ballot - Normative version. There are some NHS England specific extensions contained in this guidance. For the full HL7 V3 2006 - Normative version documentation on data types, readers should consult the HL7 V3 Ballot pack. A data type is identified by [D] after the name.

All HL7 data types were originally derived from the data types defined in the W3C schema recommendation. However, the HL7 data types were defined as those best suited to meet the requirements of healthcare messaging and this accounts for some of the differences between them and the native W3C XML Schema data types.

Some simple data types such as Boolean are restrictions on the W3C version, with the values "true and "false" being allowed, but not 0 and 1, which have proved a source of confusion in messaging implementations. Others are more loosely defined, such as TS (Time Stamp) which is implemented as a union of many of the W3C date/time data types.

Where a data type component is intended to be used externally its name is in capitals (e.g. TS), and where is intended only for use in as a part of another data type, the name is in lower case (e.g. center, low and high which is used by IVL_TS).

HL7 Version 3 provides a rich set of possible variants on a set of relatively complex data types. For the purposes of an individual specification, there may be a need to constrain a data type further. A data type that has been further constrained is a data type flavor (flavor). The flavors specified here are for a NHS England domain, or domains. Each of the permitted flavors is, specified in full, assigned a name and described in the section for the data type it constrains. A data type flavor is identified by [F] after the name. There are two types of flavors:

• A flavor that is defined in the datatypeflavors.xsd and therefore is enforced to some extent. This type of flavor will have a specific identifier (for example ON.NHS.OrganizationNameType1) as well as a name. Note: A message that uses a particular named data type flavor may not be always be bound to the flavor in the schema. This is more often in older messages where technical constraints with tooling mean it was not possible to bind the message schema to the data type flavor schema.
• A flavor that is defined in text within the tabular view or some associated guidance and will not have an identifier only a name.

As stated above HL7 Version 3 provides a rich set of possible variants on a set of relatively complex data types. However, there is on rare occasions a need to extend data types for a very specific NHS use case.

This guidance describes the extensions made to the HL7 data types and gives rational for the need for the extension. The majority of these extensions were utilised in the early days of the National Programme when HL7 standard was still in its infancy. There was a desire at the time to get the extensions included into the HL7 standard. For multiple reasons some of the extensions have not made it into the HL7 standard. Therefore, these remain as NHS England specific extensions to the HL7 standard and are identified by [E] after the name.

Within the HL7 V3 standard, all classes and attributes support null flavor (nullFlavor). The “nullFlavor” attribute is a property of every data type through extension. The ”nullFlavor” attribute is valued and communicated as part of a message when information is missing. The ”nullFlavor” can provide the reason why the information is missing. For example:

An unconscious patient arrives at the hospital and during registration; there is an issue, as most Patient Administration systems need at least one address. If the patient address is unknown then the patient address field on the system records the value unknown. In a subsequent message, the address element "addr" can be set to a ”nullFlavor” of “UNK” and sent to other down stream systems or repositories.

Notes:

• A "nullFlavor” attribute is normally only usable if the HL7 V3 model attribute is not mandated. The individual data type descriptions may state a ”nullFlavor” is allowable. However, when a “nullFlavor” is utilised in a message instance then the schema and tabular view for the actual HL7 model attribute may expose other constraints of the actual usage of ”nullFlavor” with the data type.
• A "nullFlavor” is allowable instead of a value but not as well as a value
• The "nullFlavor” attribute never appears on the HL7 V3 model.

This data type guidance describes each data type, data type flavor and data type extension in use across the HSCIC Interoperability Domain Message Specifications. Implementers should be aware that the tabular view documentation along with the domain conformance schemas should be utilised when creating instances of messages for information on which XML elements or XML attributes are usable for a given message. When there is a conflict between the two definitions then the tabular view takes precedence

If there is no guidance provided for an XML element or XML attribute in the tabular view then there is no requirements for that XML element or XML attribute to be populated in an “on the wire” instance.

In the instance examples provided the xsi:type attribute is shown in the value elements of observation for completeness, the tabular views for the domain must be consulted as to whether the xsi:type should be included. When the tabular view does not give guidance of use of xsi:type then the recommendation is to include the xsi:type if the schema supports use of the xsi:type attribute.

Example 1:

<value xsi:type="REAL" value="2.3"/>

Example 2: The examples also may have the end tags shown in one of two ways, this is to make it clearer when the XML element contains data or just XML attributes.

<value xsi:type="REAL" value="2.3"/>

Example 3: or

<value xsi:type="REAL" value="2.3"/>

These are data values that comprise generic collections of data values of a single data type. Four concern us here:

• BAG - This is an unordered collection of data values. A data value may occur more than once. Where the collection of the integers (17, 2, 13, 2, 99, and 17) would be a BAG.
• LIST - This is an ordered collection of distinct data values. Where the collection of the integers (2, 13, 17, and 99) would be a LIST.
• SET - This is a collection of distinct data values in no particular order. Where the collection of the integers (17, 13, 99, and 2) would be a SET.
• IVL - This is a set of consecutive values.

Data type overview:

XML Usage:

PostAddress Use Values

Code Usage:

Flavours:

Unstructured Address [F]

<addr>106 Goodwin Street Leeds LS1 4HY</addr>

Unstructured Address with optional postal code, use and valid time [F]

<addr use="H">106 Goodwin Street Leeds LS1 4HY</addr>

<addr>106 Goodwin Street
 <useablePeriod>
  <low value="20000706"/>
  <high value="20110806"/>
 </useablePeriod>
</addr>

<addr use="H">106 Goodwin Street Leeds
 <postalCode>LS1 4HY</postalCode>
</addr>

<addr>106 Goodwin Street Leeds LS1 4HY
 <useablePeriod>
  <low value="20000706"/>
  <high value="20110806"/>
 </useablePeriod>
</addr>

Address streetAddressLine (PDS Style) [F]

<addr use="H">
 <streetAddressLine>Pynes Hill</streetAddressLine>
 <streetAddressLine>Rydon Lane</streetAddressLine>
 <streetAddressLine>Exeter</streetAddressLine>
 <streetAddressLine>Devon</streetAddressLine>
 <postalCode>EX2 5SE</postalCode>
 <addressKey>12345678</addressKey>
</addr>

<addr use="TMP">
 <streetAddressLine>AQUEOUS II</streetAddressLine>
 <streetAddressLine>ASTON CROSS</streetAddressLine>
 <streetAddressLine>ROCKY LANE</streetAddressLine>
 <streetAddressLine>ASTON</streetAddressLine>
 <streetAddressLine>BIRMINGHAM</streetAddressLine>
 <postalCode>B6 5RQ</postalCode>
 <addressKey>23456789</addressKey>
  <useablePeriod>
    <low value="20040716"/>
    <high value="20040831"/>
  </useablePeriod>
</addr>

Address fully structured [F]

<addr use="H">
 <houseNumber>Rose Cottage</houseNumber>
 <streetName>Pynes Hill</streetName>
 <streetName>Rydon Lane</streetName>
 <city>Exeter</city>
 <county>Devon</county>
 <postalCode>EX2 5SE</postalCode>
 <addressKey>12345678</addressKey>
</addr>

<addr use="WP">
 <houseNumber>Hexagon House</houseNumber>
 <streetName>Pynes Hill</streetName>
 <streetName>Rydon Lane</streetName>
 <precinct>Whipton</precinct>
 <city>Exeter</city>
 <county>Devon</county>
 <country>England</country>
 <postalCode>EX2 5SE</postalCode>
 <addressKey>12345678</addressKey>
</addr>

<addr nullFlavor="UNK"/>

<addr use="WP">
 <houseNumber nullFlavor="UNK"/>
 <streetName nullFlavor="UNK"/>
 <precinct>Whipton</precinct>
 <city>Exeter</city>
 <county>Devon</county>
 <country>England</country>
 <postalCode>EX2 5SE</postalCode>
 <addressKey>12345678</addressKey>
</addr>

Use of nullFlavor with addr Data Type and flavors

<addr nullFlavor="UNK"/>

<addr use="WP">
 <houseNumber nullFlavor="UNK"/>
 <streetName nullFlavor="UNK"/>
 <precinct>Whipton</precinct>
 <city>Exeter</city>
 <county>Devon</county>
 <country>England</country>
 <postalCode>EX2 5SE</postalCode>
 <addressKey>12345678</addressKey>
</addr>

A HL7 V3 model attribute which utilises the abstract data type ANY may be any one of the other data types listed below, such as BL, ST, CV, PQ, TS, etc. Normally it will be resolved to one of the more specific data types within an “on the wire" instance of a message.

BL stands for the values of two-valued logic. A BL value can be true, false or NULL (set to a nullFlavor). A HL7 V3 model attribute which uses the data type BL has an XML element containing one XML attribute "value", which shall contain true or false.

XML Usage:

Example 1: To indicate a context conduction indicator with value "true"

<contextConductionInd value="true"/>

Example 2: To indicate a seperatable indicator with value "false"

<seperatableInd value="false"/>

Example 3: To indicate a seperatable indicator where the value is unknown

<seperatableInd nullFlavor="UNK"/>

BN constrains the Boolean type so that the value may not be NULL. This type was created for use within the data type’s guidance where it is not appropriate for a null value to be used. A HL7 V3 model attribute which uses the data type BN has an XML element containing one XML attribute “value”, which shall contain true or false.

Data type overview:

XML Usage:

Example 1: When sending the Boolean value to indicate a context conduction indicator with value "true"

<contextConductionInd value="true"/>

Example 2: When sending the Boolean value to indicate a seperatable indicator with value "false"

<seperatableInd value="false"/>

The character string data type is used for text data. Used for names, symbols, and formal expressions. The ST data type is used when the appearance of text does not bear meaning, which is true for formalized text and all kinds of names. A HL7 V3 model attribute, which uses the data type ST, has an XML element containing the text. The XML element will take its name from the HL7 V3 model attribute name.

Data type overview:

XML Usage:

Flavours:

Character String (ST.NHS.StringType5) Representation in Messages

<name>Mary Jones</name>

<text>Some plain text</text>

<value xsi:type="ST">Some plain text</value>

<name nullFlavor="UNK"/>

<text nullFlavor="UNK"/>

<value nullFlavor="UNK"/>

The character string with code data type consists of a character string that optionally may have a code attached. The text must always be present if a code is present. The code is often a local code. A HL7 V3 model attribute, which uses the data type SC, has an XML element containing the text. The XML element will have XML attributes to carry the coding information. The XML element will use the HL7 V3 model attribute name.

Data type overview:

XML Usage:

Flavours:

Character String with Code Representation in Messages

<softwareName>NHAIS</softwareName>

<softwareName code="1" codeSystem="2.16.840.1.113883.2.1.3.2.9999" displayName="NHAIS">NHAIS</softwareName>

<softwareName nullFlavor="UNK"/>

CS is used to convey information on the form of a code only. This is only used where there is a short controlled list of possible values, and typically these will be HL7 V3 defined structural codes where the coding system can reliably be inferred by context..

CV is used where there is no requirement from sending translations or qualifiers, otherwise it has the same structure as the CD data type. It must either have the NULL attribute, or all three of code , displayName and codeSystem .

CE is used where the approved coding scheme is not the original scheme in which the data was encoded. However, it is not applicable where qualifiers are required. The original code is mapped to a translated code in the approved scheme. The mapping may translate a specific original code to a more general code in the approved scheme but must not add specificity not present in the original code.

An HL7 V3 model attribute of type CD may either have a NULL attribute or all three of: code , displayName and codeSystem .

The code attribute holds the code value, and displayName is the rubric associated with that code. This is the text as provided by the maintainer of the code list, and must not be changed in any way by the sending system. Where there is any difference in the text, this variation should be sent in the optional originalText attribute . The codeSystem attribute must be supplied for all non-NULL instances of this data type, and is the OID for the coding system from which the code has been drawn. See the HL7 V3 specification for full details of the OID structure.

Two optional child elements allow code qualifiers (" qualifier " element) and alternate coding system representation of the same information (" translation " element).

Note that where a translation is used the original code used is expressed in the outer element. The translation element is used to send the required encoding. For example, the translation should be used to send a SNOMED CT concept identifier if clinical information was originally collected using some other coding system.

Note that this domain specification pre-adopts a committee proposal for extension of the qualifier structure to allow grouping of qualifiers. This proposal has been pre-adopted to support accurate representation of SNOMED CT "role grouping".

Representation within messages:

Flavours:

Coded Plain (CV.NPfIT.Codedplain) [F]

<value xsi:type="CV" code="11" codeSystem="2.16.840.1.113883.2.1.3.2.4.17.42" displayName="NHS Number confirmed"/>

Coded with Original Text (CV.NPfIT.CodedOriginaltext) [F]

<code code="195967001" codeSystem="2.16.840.1.113883.2.1.3.2.4.15" displayName="asthma">
 <originalText>currently suffering from asthma</originalText>
</code>

Coded Qualified [F]

<code code="405613005" displayName="Planned procedure" codeSystem="2.16.840.1.113883.2.1.3.4.15">
 <originalText>
  <reference value="#a3"/>
 </originalText>
  <qualifier>
   <name code="36589002" displayName="Associated procedure"/>
   <value code="2254260907" displayName="Administration of therapeutic substance">
     <qualifier>
      <value code="112239003" displayName="by inhalation"/>
     </qualifier>
    </value>
  </qualifier>
</code>

Coded Translated [F]

<code code=".H43." codeSystem="2.16.840.1.113883.6.28" displayName="asthma">
 <originalText>currently suffering from asthma""</originalText>
  <translation code="195967001" codeSystem="2.16.840.1.113883.2.1.3.2.4.15" displayName="asthma"/>
</code>

Coded Only (CV.NPfIT.Codeonly) [F]

<administrativeGenderCode code="2"/>

Coded with Display Name (CV.NPfIT.CodedDisplayname) [F]

Coded with Code System (CV.NPfIT.CodedCodeSystem) [F]

<confidentialityCode code="S" codeSystem="2.16.840.1.113883.2.1.3.2.4.16.1"/>

The Encapsulated Data data type is utilised when the data is primarily intended for human interpretation or for further machine processing outside the scope of HL7. This includes unformatted or formatted written language, multimedia data, or structured information in as defined by a different standard (e.g., XML-signatures.) Where the data is included in the element, it is sent as the element content. The XML element will use the HL7 V3 model attribute name. See examples below.

Alternatively, it can be sent as a URL using the optional "reference" child. If this reference element is used, then there should not be any other content in the ED-typed element (i.e. data must either be sent inline, or by reference, but both should not be done at the same time). The reference element is of type TEL, with attributes for the URL, the use type, and an optional validTime child element to specify when the linked data is useable.

Data type overview:

XML Usage:

Flavours:

ED.NHS.Data.Representation.MediaType.Mandated [F]

<value xsi:type="ED" representation="B64" mediaType="image/jpeg">
/9j/4AAQSkZJRgABAQEASABwAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQOOK1K2gcldp2sf/Z
</value>

<text mediaType="application/pdf" representation="B64">
        JVBERi0xLjUN .......
</text>

StrucDoc.Text [F]

An identifier that uniquely identifies a thing or object. Examples are object identifier for HL7 RIM objects, medical record number, order id, service catalog item id, Vehicle Identification Number (VIN), etc. Instance identifiers are defined based on ISO object identifiers..

"Real world" identifiers such as a GMCP number or a patient NHS Number should be sent in the extension attribute, with the root being used to identify the assigning authority that is responsible for ensuring the uniqueness of the identifier in the extension.

An alternative mechanism is used for identifiers that are used to maintain instances of information as that information becomes distributed as a result of messaging. In this case there is no single authority that can be made responsible for maintaining the uniqueness, and so DCE UUIDs are normally used (Universally Unique IDs). These must be generated in a way that ensures uniqueness, and be expressed as dash separated hexadecimal numbers. The DCE UUID is sent in the root attribute.

Flavours:

Identifier Global (II.NPfIT.uuid.mandatory) [F]

<id root="BBBBE26A-A9D1-A411-F824-9F7A00A33757"/>

Identifier External [F]

<id root="2.16.840.1.113883.2.1.4.1" extension="9999999484"/>

Identifier External OID mandatory (II.NPfIT.oid.mandatory) [F]

<id root="2.16.840.1.113883.2.1.4.1" extension="9999999484"/>

Identifier External ODS Organisation or Site (II.NPfIT.OrganizationSDS.Organisation.oid or II.NPfIT.OrganizationSDS.Site) [F]

<id extension="V145" root="2.16.840.1.113883.2.1.3.2.4.19.1"/>

Identifier External with Optional Assigning Authority (II.NPfIT.oid.mandatory.assignedAuthority) [F]

<id root="2.16.840.1.113883.2.1.4.1" extension="9999999484" assigningAuthorityName="V145:V145:LONDON BOROUGH OF ISLINGTON"/>

Identifier External with Mandatory Root Enumerated OID and Optional Assigning Authority (II.NPfIT.oid.mandatoryAndEnumerated.assignedAuthority.optional) [F]

<id root="2.16.840.1.113883.2.1.4.1" extension="9999999484" assigningAuthorityName="V145:V145:LONDON BOROUGH OF ISLINGTON"/>

Identifier External Extension Only (II.NHS.extension.mandatory) [F]

<id extension="9999999484"/>

Integer numbers (-1, 0, 1, 2, 100, 3398129, etc.) are precise (whole) numbers that are results of counting and enumerating. Integer numbers are discrete; the set of integers is infinite but countable. There are no arbitrary limits imposed on the range of integer numbers. There are two NULL flavors defined for the positive and negative infinity. A HL7 V3 model attribute, which uses the data type INT, has an XML element containing one XML attribute "value".

Data type overview:

XML Usage:

Flavours:

Integer Number Representation in Messages

<repeatNumber value="1"/>

<sequenceNumber nullFlavor="UNK"/>

A range of physical quantity can either be expressed using "low" and "high" child elements to define the bounds of the interval (if only one of these is sent, then the other is assumed to be unbounded), or by sending the "center" element to express a single quantity instead of a range.

Flavours:

Quantity Range [F]

<value xsi:type="IVL_PQ">
 <low value="3.6" unit="mmol/l"/>
 <high value="5.3" unit="mmol/l"/>
</value>

Quantity Greater than [F]

<value>
 <low value="3.6" unit="mmol/l"/>
</value>

Quantity Less than [F]

<value>
 <high value="5.3" unit="mmol/l"/>
</value>

A time interval can either be expressed using "low" and "high" child elements to define the bounds of the interval. If only one of these is sent, then the other is assumed to be unbounded. Alternatively, by sending the "center" element to express a single point in time. Finally the "width" element can be used to express a duration which is not fixed to a particular point in time. The "width" would be used to state that a symptom lasted for 30 minutes, without having to state the exact time that this occurred. Note that if both "center" and "width" are present, then neither "low" nor "high" may be included.

Flavours:

Date or Time Point [F]

<effectiveTime>
 <center value="200406251205"/>
</effectiveTime>

Date or Time Interval Complete [F]

<effectiveTime>
 <low value="200406251205"/>
 <high value="200406251220"/>
</effectiveTime>

Date or Time Interval After [F]

<effectiveTime>
 <low value="200406251205"/>
</effectiveTime>

Date or Time Interval Before [F]

<effectiveTime>
 <high value="20040625"/>
</effectiveTime>

An organisational name is always unstructured, and is sent as string content of the element

XML Usage:

Flavours:

Organisation Name (ON.NHS.OrganizationNameType1) [F]

<name>Good Health Hospital</name>

Organisation Name with Valid Time [F]

<name>Good Health Hospital
 <validTime>
  <low value="19990401"/>
  <high value="20040331"/>
</validTime>
</name>

Use of nullFlavor with ON Data Type and flavors

<name nullFlavor="UNK"/>

Person Name is used to express either an unstructured name as string content of the name XML element, or a structured name as a set of family, given, prefix and suffix child XML elements. If any of the child XML elements are used, then there shall be no string content in the parent name XML element (i.e. the name must be structured or unstructured). In a structured name, there may be only one family element for the family name, and one prefix element for the title. The text values of the family, given, prefix and suffix XML elements are only allowable as element content. If the name is available in both structured and unstructured forms, the structured form shall be preferred. For both structured and unstructured names, the use of the name is allowable as a single optional XML attribute of the name XML element.

XML Usage:

The name XML element has a "use" XML attribute, which utilise a set of codes that can be used for advising a system, or user, which name in a set of names to select for a given purpose. The full list of codes are shown below but implementers should refer to the relevant tabular view for further guidance as these values may be further constrained for particular messages.

Code Usage:

Flavours:

Person Name Unstructured [F]

<name>John Smith</name>

<name>Paula Charlotte Adamson</name>

<name>Dr. Alan Smith</name>

<name>Sir Terry Jones KBE</name>

Person Name Unstructured with Use [F]

<name use="L">John Smith</name>

Person Name Unstructured with Valid Time [F]

<name>John Smith
 <validTime>
  <low value="19990401"/>
  <high value="20040331"/>
 </validTime>
</name>

Person Name Unstructured with Use and Valid Time [F]

<name use="A">John Smith
 <validTime>
  <low value="19990401"/>
  <high value="20040331"/>
 </validTime>
</name>

Person Name Structured [F]

<name>
 <prefix>Mr</prefix>
 <given>John</given>
 <given>Paul</given>
 <family>Smith</family>
 <suffix>BSc</suffix>
</name>

Person Name Structured with Use [F]

<name use="L">
 <prefix>Mr</prefix>
 <given>John</given>
 <given>Paul</given>
 <family>Smith</family>
 <suffix>Snr</suffix>
</name>

Person Name Structured with Valid Time [F]

<name>
 <prefix>Mr</prefix>
 <given>John</given>
 <given>Paul</given>
 <family>Smith</family>
 <suffix>Snr</suffix>
 <validTime>
  <low value="19990401"/>
  <high value="20040331"/>
</validTime>
</name>

Person Name Structured with Use and Valid Time [F]

Person Name Structured with Optional Use and Optional Valid Time [F]

<name use="A">
 <prefix>Mr</prefix>
 <given>John</given>
 <given>Paul</given>
 <family>Smith</family>
 <suffix>Snr</suffix>
 <validTime>
  <low value="19990401"/>
  <high value="20040331"/>
 </validTime>
</name>

<name use="L">
 <prefix>Mr</prefix>
 <given>John</given>
 <given>Paul</given>
 <family>Smith</family>
 <suffix>Snr</suffix>
 <validTime>
  <low value="19990401"/>
  <high value="20040331"/>
 </validTime>
</name>

Person Name with Mandatory Given and Family (PN.NHS.PersonNameType6) [F]

<name>
 <given>John</given>
 <given>Paul</given>
 <family>Smith</family>
</name>

Use of nullFlavor with PN Data Type and flavors [F]

<name nullFlavor="UNK"/>

<name>
 <prefix nullFlavor="UNK"/>
 <family>Blair</family>
 <given>Albert</given>
</name>

Physical quantities are expressed using the two attributes "value" and "unit". Where the measurement was originally taken in a different unit, then this can be sent in addition using the "value", "code", "codeSystem" and "displayName" attributes of the "translation" child element.

Flavours:

Quantity in Standard Units [F]

<value value="92.55" unit="%"/>

Quantity in Alternative Units [F]

<quantity value="30" unit="g">
 <translation value="30" code="258682000" codeSystem="2.16.840.1.113883.2.1.3.2.4.15" displayName="gram"/>
</quantity>

<quantity value="100" unit="1">
 <translation value="100" code="3319411000001109" codeSystem="2.16.840.1.113883.2.1.3.2.4.15" displayName="tablet"/>
</quantity>

Quantity in Arbitrary Units [F]

<value value="6" unit="1">
 <translation value="6">
 <originalText>packets each containing 21 tablets of A and 7 tablets of B</originalText>
 </translation>
</value>

The time stamp is sent in the "value" attribute of this data type. Time stamp information is sent in a format that is simplest for the XML schema to validate, as follows: YYYYMMDDHHMMSS[+|-ZZzz], where YYYY is the year, MM the month, DD the day, HH the hour, MM the minutes, SS.the seconds and +|-ZZzz is the time zone offset in hours and minutes. Sections from the right of this representation may be left off to send an imprecise date, thus "2000" would be a valid value for TS, indicating sometime in the year 2000. A timestamp precise down to the hour would be "2000040103". A timestamp precise down to the second would look like "20000401031520".

Flavours:

Date and Time [F]

<effectiveTime value="200406251205"/>

<effectiveTime value="200406251205.055"/>

Date Year, Month, Day, Hour and Minute (TS.NHS.DateType1) [F]

<effectiveTime value="201211070900"/>

Date Only [F]

<effectiveTime value="20040625"/>

Date Month [F]

<birthTime value="200406"/>

Date Year [F]

<birthTime value="2004"/>

An element of the abstract type QTY may be any one of the data types INT (integer), REAL (real), MO (money), TS (time stamp), PQ (physical quantity) and RTO (ratio of quantities) - for all except MO see above or below. It shall be resolved to one of these more specific data types when an instance of a message using it is generated. It is also used in defining certain other data types, such as IVL (interval). This represents the global HL7 V3 standard, and is not an domain specific flavor.

A ratio of integers is expressed using two child elements "numerator" and "denominator", both of type INT.

XML Usage:

Example 1: To indicate a ratio of 1:128 for a "value" attribute of an observation class

<value>
 <numerator value="1"/>
 <denominator value="128"/>
</value>

A ratio of physical quantities is expressed using two child elements "numerator" and "denominator", both should be sent and are of type PQ. They must both be expressed using the same units.

XML Usage:

Example 1: To indicate a ratio of 1:128 for a "value" attribute of an observation class

<value>
 <numerator value="1" unit="1"/>
 <denominator value="128" unit="1"/>
</value>

Real numbers are fractional numbers. Typically used whenever quantities are measured, estimated, or computed from other real numbers. The typical representation is decimal, where the number of significant decimal digits represents the precision. A HL7 V3 model attribute, which uses the data type REAL, has an XML element containing one XML attribute “value”.

Data type overview:

XML Usage:

Flavours:

Real Representation in Messages

<value xsi:type="REAL" value="2.3"/>

<value nullFlavor="UNK"/>

Telephone numbers pager and email addresses and references to external data by the ED data type are all expressed using the URL syntax as described in the HL7 V3 documentation. Note that specification of the type of the address (e.g. fax or email) is built into the URL itself.

Data type overview:

XML Usage:

The codes for the XML attribute use are:

Code Usage:

Flavours:

Telecommunication address [F]

<telecom value="tel:01392251289"/>

<telecom use="HP" value="tel:01392251289"/>

<telecom use="WP" value="fax:01392251689"/>

<telecom use="MC" value="tel:07700012345">
 <useablePeriod>
  <low value="20040401"/>
 </useablePeriod>
</telecom>

<telecom value="mailto:joe.bloggs@myisp.co.uk"/>

Telecommunication Address with Use and Useable Period (TEL.NPFIT.use.required) [F]

<telecom use="MC" value="tel:07700012345"/>

<telecom nullFlavor="UNK"/>

Telephone Number with Use (TEL.NHS.value.mandatory) [F]

<telecom use="MC" value="tel:07700012345"/>

A restriction of entity name that is effectively a simple string used for a simple name for things and places.

Trivial names are typically used for places and things, such as Lake Windermere or Leeds Bradford Airport:

Data type overview:

XML Usage:

Example 1: To indicate a place name

<name>Lake Windermere</name>

Example 2:

<name>Leeds Bradford Airport</name>